Network Supervisor's Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ Network Supervisor's Toolkit / Network Supervisor's Toolkit.iso / novell / fyidev / fyi_a.net < prev next >

Wrap

Text File | 1996-07-10 | 59.5 KB | 1,818 lines

FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Brequest v6.0 /l Option DOCUMENT ID#: FYI.A.2043 DATE: 04FEB93 PRODUCT: NetWare Btrieve NLM PRODUCT VERSION: 6.0 SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM Brequest version 6.00x has a new load option, /l. This allows another instance of Brequest to be loaded even if Brequest is already loaded. This option is useful if the ability to run Windows applications utilizing the Btrieve requester at the same time running DOS VM applications using Brequest is desired. To run Windows applications utilizing the Btrieve requester, Brequest must be loaded before starting Windows. To run DOS applications in Windows, Brequest must be loaded in each DOS session. However, if Brequest is loaded outside of Windows, it cannot be loaded again in a DOS session. FYI.A.2022 addresses this issue by suggesting the use of WINSTART.BAT to load Brequest before Windows. However, FYI.A.6101 points out that Windows 3.1 will hang sporadically on exit if TSRs are loaded with the WINSTART.BAT. SOLUTION Load Brequest outside of Windows for Windows applications utilizing the Btrieve requester. In each Windows DOS session that will be running a Btrieve application, load BREQUEST /l. This will load another instance of Brequest that is only available to the DOS session. This provides the DOS session with its own copy of Brequest and prevents the DOS session from using the instance of Brequest that was loaded before Windows was started. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: File Level Access Using Different Versions of Brequest DOCUMENT ID#: FYI.A.3021 DATE: 28JAN93 PRODUCT: NetWare Btrieve NLM PRODUCT VERSION: 6.0 SUPERSEDES: NA SYMPTOM NetWare allows Btrieve to write to files without appropriate user rights. ISSUE/PROBLEM With Brequest v5.16, a user is able to write to a Btrieve file if the user has Write access to the directory, even if the user does not have Write access to the file. SOLUTION This problem does not exist if Brequest 6.0 is used. Brequest 6.0 uses File level access rather than Directory level access. If a user has RWCEMFA access to a directory but only RF (read and file scan) access to a file, Brequest 6.0 will return a status 94 on the open call. However, Brequest 5.16 will return status 0, and the file can be updated. The Supervisor access to a directory works differently, however. If the user has Supervisor access, then the file can be opened regardless of the requester version. This is mainly because Supervisor rights "override all Inherited Rights Masks in subdirectories and files." Directory Trustee File Trustee Btrieve 6.0 Btrieve 5.16 Assignment Assignment Status Status RWCEMFA R F 94 0 FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Brequest and TaskMAX DOCUMENT ID#: FYI.A.1773 DATE: 26JAN93 PRODUCT: NetWare Btrieve NLM PRODUCT VERSION: 6.0 SUPERSEDES: NA SYMPTOM Status 95; Session hung ISSUE/PROBLEM Can the DR DOS utility TaskMAX be used to run DOS Btrieve applications using the NetWare Btrieve requester? SOLUTION Since TaskMAX is a task switching utility, and not a multi-tasking operating system, only the current task is active. Loading Brequest in a TaskMAX session, and then running a Btrieve application will work, until the user switches to another task. At this point, trying to switch back to the Btrieve task will result in either a hung session, or a status 95 (Session No Longer Valid) returned to the session. This is because the SPX session between Brequest and NetWare Btrieve on the server can not be maintained when a session becomes inactive. An alternative would be to load Brequest before starting TaskMAX. However, with this configuration, only one session can be running a Btrieve application, but this session can be switched out for other non-Btrieve sessions, and resumed successfully. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Determining If an Application Is Running In Windows DOS Box DOCUMENT ID#: FYI.A.6102 DATE: 21JAN93 PRODUCT: Btrieve for Windows PRODUCT VERSION: 5.10a SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM How can it be determined if a DOS application is running under Windows? SOLUTION An interrupt is available to determine if a DOS application is running under Windows 3.1. The following assembly code demonstrates the interrupt. This function call also will determine if Windows 3.1 is running in 386 Enhanced Mode or Standard Mode. If the function determines that Windows 3.1 is running, it sets CX equal to 2 if Windows is running in Standard Mode. If Windows is running in Enhanced mode, it sets CX equal to 3. mov ax, 160ah ; int 2fh ; Check if in Windows 3.1 DOS box or ax, ax ; jz Windows31 ; Jump if Windows 3.1 FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Btrieve Operation 42 (Continuous Operation) Usage DOCUMENT ID#: FYI.A.1774 DATE: 18JAN93 PRODUCT: NetWare Btrieve NLM PRODUCT VERSION: 6.0 SUPERSEDES: NA SYMPTOM Status 20 - Btrieve not loaded; Status 1 - Invalid Operation ISSUE/PROBLEM The new Btrieve 6.0 operation 42, which allows Btrieve files to be placed into Continuous Operation, and removed from Continuous Operation, can only be called from an NLM application. It can not be called from a workstation application. If a workstation attempts to make a Btrieve operation 42, a status 20 (Btrieve Not Loaded) will be returned. Btrieve version 5.x will return a status 1 (Invalid Operation). SOLUTION The Btrieve 6.0 SDK includes a sample NLM application that demonstrates the usage of operation 42. Both the C source code and the compiled NLM are included. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Brequest and Older Version of VIPX.386 DOCUMENT ID#: FYI.A.3022 DATE: 13JAN93 PRODUCT: NetWare Btrieve NLM PRODUCT VERSION: 6.0 SUPERSEDES: N/A SYMPTOM Windows Dos Box hangs upon exit if Brequest is not unloaded. ISSUE/PROBLEM If Brequest is not unloaded before exiting a Windows Dos Box, the workstation will hang. This only happens if VIPX.386 version 1.11 (19197 bytes dated 3-10-92) is used. SOLUTION This problem does not exist if VIPX.386 v1.13 is loaded (24362 bytes dated 09-4-92). FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Btrieve 6.0 and NetWare for SAA 1.3 DOCUMENT ID#: FYI.A.2520 DATE: 13JAN93 PRODUCT: NetWare Btrieve NLM PRODUCT VERSION: 6.0 SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM If users of NetWare for SAA want to use their file server as a database server, they will need to get the Btrieve requesters and utilities from NetWire or from Technical Support, Austin. NetWare for SAA 1.3 was bundled with the following Btrieve components: Brebuild.nlm 1.0b 34,347 11-16-82 4:31p Brouter.nlm 6.0 16,767 5-11-92 1:19p Bsetup.hlp 6.0 29,462 7-21-92 10:02a Bsetup.nlm 6.0 32,275 7-29-92 10:44a Bspxcom.nlm 6.0a 13,871 8-05-92 10:05a Bspxstub.nlm 6.0 596 3-16-92 12:59p Bstart.ncf 6.0 99 8-03-92 1:09p Bstop.ncf 6.0 49 4-12-92 2:46p Btrieve.nlm 6.0b 146,258 12-01-92 11:06a Btrieve.org 6.0 145,193 5-12-92 10:08a Btrmon.hlp 6.0 28,568 7-09-92 9:52a Btrmon.nlm 6.0 56,856 7-16-92 2:13p Btrun.nlm 6.0 8,742 9-09-92 1:16p Butil.nlm 6.0 124,219 7-29-92 10:50a Patch311.nlm (Dummy) 798 9-16-92 9:58a Rspxstub.nlm 6.0 1,137 3-16-92 1:00p SOLUTION NA FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Running BREQUEST 6.0b and XQLP(O) with 2.01a DOCUMENT ID#: FYI.A.1880 DATE: 11JAN93 PRODUCT: XQL for DOS PRODUCT VERSION: 2.01x SUPERSEDES: NA SYMPTOM "Btrieve not Loaded" error ISSUE/PROBLEM The following steps will cause XQLP(O) to return the message BTRIEVE NOT LOADED when trying to load XQLP(O). 1) Load BREQUEST 6.0x 2) Load XQLP or XQLPO 2.01x 3) Unload XQLP(O). 4) Reload XQLP(O). The error message will appear at this point. After this, BREQUEST appears to be in memory but running a STOP operation on Btrieve reports that Btrieve is not loaded. However, BREQUEST will not reload. SOLUTION Rebooting the workstation is the only way to remove BREQUEST from memory. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: NetWare Resources Does Not Appear Under OS/2 DOS Settings DOCUMENT ID#: FYI.A.1952 DATE: 07JAN93 PRODUCT: Btrieve OS/2 PRODUCT VERSION: 5.10 SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM To run Brequest in a DOS session under OS/2, there are a few options, depending on whether the DOS sessions is Global or Private. This can be configured in OS/2 2.0 (refer to FYI.A.1870). However, if the VSHELL.SYS device driver is not loaded, the "NetWare Resources" option will not appear in the DOS Settings menu. This is the option that allows the configuration of Global or Private DOS box. SOLUTION Make sure that VSHELL.SYS is loaded in the CONFIG.SYS file. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Btrieve Continuous Operations and File Logging DOCUMENT ID#: FYI.A.4203 DATE: 01OCT92 PRODUCT: NetWare Btrieve PRODUCT VERSION: 6.0 SUPERSEDES: NA SYMPTOM Logging when used in conjunction with Continuous Operations may lead to an inconsistent database. ISSUE/PROBLEM File logging and backups can be used to rebuild Btrieve files in case of system failures. Continuous Operations allow continuous access to Btrieve files while the files are being backed up. These two features can not be used simultaneously. While a file is in Continuous Operation mode, the log file is still open and being updated. If logging is activated when the file is put into Continuous Operations mode, eventually the file will not be in sync with the log file. Consider the following scenario: 1. Get a backup of the Btrieve file. 2. Activate logging. 3. Touch the file (update, delete, insert). 4. Start Continuous Operations. 5. Touch the file. 6. Backup is complete; end Continuous Operations. At this point if a power failure occurred, the backup from step 4 would be restored. The backup would reflect all the changes that were made in step 3. The log file, however, would contain both the changes made in step 3 and step 5. So if the log file is used at a later date, in conjunction with the latest backup from step 6, some operations in the log file are already present in the Btrieve file, and errors during the Roll Forward process will most likely occur. SOLUTION Do not use logging and Continuous Operations at the same time. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Multiple Record Locks and DOS 4.01 DOCUMENT ID#: FYI.A.4204 DATE: 01OCT92 PRODUCT: Btrieve for DOS PRODUCT VERSION: 5.10a SUPERSEDES: NA SYMPTOM If more than 20 records were locked using Multiple Record Locks, a status 81 was returned. ISSUE/PROBLEM An application using Btrieve for DOS v5.10a with DOS v4.01 returned status 81 when the application attempted to lock more than 20 records with multiple locks. Raising the Btrieve /L parameter had no effect. The same application was running on another workstation without problem. This workstation was running DOS v5.0. The AUTOEXEC.BAT and CONFIG.SYS files on both PCs were identical. SOLUTION The user upgraded to DOS v5.0 and problem was resolved. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Router Problem under NetWare v3.11 DOCUMENT ID#: FYI.A.3228 DATE: 03FEB93 PRODUCT: Network C for NLMs PRODUCT VERSION: 2.0e SUPERSEDES: NA SYMPTOM SAPs are disappearing as they cross routers. ISSUE/PROBLEM When the NetWare v3.11 router code was written, it was not expected that one would advertise multiple service names on the same network node and socket number. When this is done, it is possible to lose some of the SAPs as they cross routers. SOLUTION The easiest solution is to design the code so that each service is supported on its own socket. An alternative way is to advertise a common service name and then as part of the "protocol," request a particular service. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: SQL Servers Not Visible on Local Segments DOCUMENT ID#: FYI.A.6201 DATE: 02FEB93 PRODUCT: NetWare OS/2 SDK PRODUCT VERSION: 2.0 SUPERSEDES: NA SYMPTOM If using an OS/2 SQL server over a WAN, the server may not be seen if a query is made on a local segment. ISSUE/PROBLEM When a PC Client is initially started up, it will issue a general service query broadcast for service 9A and receive back a list of all 9A services beyond the router. If the 9A server is on the local segment, it will not be included in the list from the router nor will it respond to the broadcast as expected. SOLUTION After the 9A server starts advertising, however, the PC Client should be able to pick up the service. If the SQL server is a 1.3 machine, it may not advertise regularly, if at all. In this case, NSD004 should fix the problem. Presently, there is no solution to the SQL server not responding to the query. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Stat() Function Does Not Return Correct Name Space. DOCUMENT ID#: FYI.A.4126 DATE: 01FEB93 PRODUCT: Network C for NLMs PRODUCT VERSION: SDKd SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM The stat() function returns 0 rather than 1 for the st_originatingNameSpace field when retrieving the status for a Macintosh file. This occurs if the file is at the root directory. SOLUTION The readdir() function returns the correct originating name space. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Using MUX Semaphores with SPX DOCUMENT ID#: FYI.A.6202 DATE: 29JAN93 PRODUCT: NetWare OS/2 SDK PRODUCT VERSION: 2.0 SUPERSEDES: NA SYMPTOM A workstation could wait infinitely for an SPX call to complete. ISSUE/PROBLEM If one issues a wait on MUX semaphores under OS/2 with one of the semaphores in the MUX list being the ECB semaphore, the apparent result is that the ECB semaphore will never clear. What really happens is that the semaphore is cleared and reset by SPX but the application is never notified of it. This results in the wait never returning if it is set to infinite. SOLUTION The problem does not occur with mutex or event semaphores. If one needs to wait on more than one semaphore, it is best to create multiple threads that individually block one each on each semaphore. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Using FP_SEG with Near Pointers DOCUMENT ID#: FYI.A.6004 DATE: 29JAN93 PRODUCT: NetWare System Calls PRODUCT VERSION: 1.0 SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM The FP_SEG macro in MicroSoft's C 6.0 and 7.0 returns a garbage segment address when passed a near pointer. SOLUTION Make sure that you pass far pointers only to this macro when using MicroSoft C. Borland C++ 3.1's FP_SEG will correctly return the current data segment of a near pointer. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Driver Load Order Using LANSUP and OS/2 v2.0 DOCUMENT ID#: FYI.A.6203 DATE: 28JAN93 PRODUCT: NetWare OS/2 SDK PRODUCT VERSION: 2.0 SUPERSEDES: SYMPTOM NA ISSUE/PROBLEM Protocols or system loads but no NetWare support. ISSUE/PROBLEM When using the OS/2 driver LANSUP, the Open DataLink Interface allowing multiple protocols on an OS/2 machine and the IBM equivalent of ODINSUP, the order in which the drivers are loaded is very important. A file exists in the release version of the requester, COEXIS.TXT, that contains an example for OS/2 1.3 and older versions of LANServer or LANManager. This example does not work properly when using OS/2 2.0 or LANSUP. Apparently there is also an error in the documentation. The result is that the machine will not load the operating system; or that it will load, but report driver errors in the process; or that a successful initialization will occur (no errors) but there will be no NetWare services due to the wrong protocols being bound to the network board. SOLUTION The proper order involves loading the LAN Server 2.0 protocol drivers first in the CONFIG.SYS file. Then the NetWare Requester statements should be loaded in the following order: device=lsl.sys run=ddaemon.exe DEVICE=LANSUP.SYS device=ipx.sysdevice=spx.sysrun=spdaemon.exedevice=nmpipe.sy sdevice=npserver.sysrun=npdaemon.exeetc ... where LANSUP replaces ODINSUP. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: OS/2 Use of Extended Attributes and NetWare DOCUMENT ID#: FYI.A.6204 DATE: 28JAN93 PRODUCT: NetWare OS/2 SDK PRODUCT VERSION: 2.0 SUPERSEDES: NA SYMPTOM OS/2 File icons may disappear after the file has been moved, copied, or restored. ISSUE/PROBLEM OS2 stores a file's icon information, as well as other data, in the file's extended attributes. NetWare 2.x does not support file extended attributes. NetWare 3.x only supports extended attributes when High Performace File System (HPSF) namespace is loaded. There was a feature under OS/2 1.x that would show a program's icon for its type associated data files that is no longer available in OS/2 2.0. Therefore, this problem may occur when upgrading from OS/2 1.x to 2.0 regardless of the NetWare version. SOLUTION If Extended Attributes are required, load the HPFS namespace NLM, OS2.NAM. Make sure that the backup software supports long file names. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: NamedPipes Return Disconnect in Error DOCUMENT ID#: FYI.A.6205 DATE: 28JAN93 PRODUCT: NetWare OS/2 SDK PRODUCT VERSION: 2.0 SUPERSEDES: NA SYMPTOM PeekPipe or ReadPipe returns 109, Pipe Broken on a valid pipe. ISSUE/PROBLEM If any attempt is made to peek or read a pipe with a 0 buffer specified, the pipe will be disconnected and error 109, pipe broken will be returned. SOLUTION Specify a buffer of at least 1 byte to be used. In the case of the peek, this will not cause a problem because the contents are left in the pipe anyway. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: PurgeSalvagableFile Spelling Difference in Windows DOCUMENT ID#: FYI.A.4604 DATE: 28JAN93 PRODUCT: NetWare C for Windows PRODUCT VERSION: 1.30 SUPERSEDES: NA SYMPTOM PurgeSalvagableFile shows as undefined under Windows ISSUE/PROBLEM The call documented as PurgeSalvagableFile in the Windows SDK is actually spelled PurgeSalvageableFile (note the extra "e") in the code. The other APIs document and code it like the Windows documentation as PurgeSalvagableFile. SOLUTION Make sure to add the extra "e" when using the Windows version of this call. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: GetServerInformation Always Returns 128 Bytes in Windows DOCUMENT ID#: FYI.A.4605 DATE: 28JAN93 PRODUCT: NetWare C for Windows PRODUCT VERSION: 1.30 SUPERSEDES: NA SYMPTOM GetServerInformation may return too much data ISSUE/PROBLEM It does not matter what structure size you specify in GetServerInformation under Windows. It will always return 128 bytes of data. SOLUTION Always allocate at least 128 bytes for the received statistics buffer to avoid overwriting memory. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Problem Sharing Semaphores Between Multiple Workstations DOCUMENT ID#: FYI.A.6005 DATE: 28JAN93 PRODUCT: NetWare System Calls PRODUCT VERSION: 1.0 SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM If several workstations attempt to open the same named semaphore using system call C5h (00h), each recognizes that they are the only one with the semaphore open. This problem only seems to occur when using this system call with MicroSoft C 6.00A and MicroSoft C++ 7.0. SOLUTION There is no workaround at this time. Even doing the system call with inline assembler instead of through int86() did not solve the problem. Use one of the C APIs or switch compilers. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Diagnostics from Windows DOCUMENT ID#: FYI.A.2674 DATE: 26JAN93 PRODUCT: NetWare C for Windows PRODUCT VERSION: 1.3 SUPERSEDES: NA SYMPTOM Diagnostic API GetServerAddressTable fails with IPXODI 2.0, and the NWIPXSPX.DLL from the 1.3 SDK. ISSUE/PROBLEM There are two problems that this FYI will address: 1) Using LSL/IPXODI version 2.0 causes GetServerAddressTable to fail. Using component number 2, the workstation crashes needing a hard reset. For component number 3, the FindComponent is not found in the component list, thus the function fails. 2) The NWIPXSPX.DLL that came with the SDK 1.3 has a problem that was addressed in an earlier FYI, concerning the NWMemmove "helper" function. It did not copy the entire diagnostic reply to the buffers if they were larger than 255 bytes. SOLUTION The only known solution is to use the IPXODI v1.20 drivers. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Bug in NLM Example Program DOCUMENT ID#: FYI.A.1529 DATE: 21JAN93 PRODUCT: Network C for NLMs PRODUCT VERSION: All versions SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM The program on Page 3-23 of the NLM Library Reference Volume 1 is incorrect. If executed as is, the custom data for the NLM, which is stored in the global variable (globalString), will be NULL. The problem is that an uninitialized global variable will be set to NULL before the program begins execution. The data is read into the variable, globalString, correctly; but this is done before the uninitialized global variables have been set to NULL. SOLUTION When creating the global variable, globalString, assign a value to the string. This will prevent the string from being set to NULL before the program executes. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: File in DOS Partition of Server Would Not Truncate DOCUMENT ID#: FYI.A.1328 DATE: 18JAN93 PRODUCT: Network C for NLMs PRODUCT VERSION: 2.00D SUPERSEDES: NA SYMPTOM A file in the DOS partition of a NetWare file server would not truncate after data was modified. ISSUE/PROBLEM A file in the DOS partition of a NetWare file server contains five lines. The application NLM reads the five lines and modifies the data to only have four lines and writes it back out. Viewing the file again indicates that the fifth line is still in the file. The following calls were being issued: ■ DOSOpen (), DOSRead (), DOSClose () ■ data was modified here ■ DOSOpen (), DOSWrite (), DOSClose () ■ file was viewed here which indicated no change had occurred SOLUTION The call to DOSWrite () does not cause the file to truncate if the data length of the file to be written is less than the original length. The DOSWrite () writes data to a particular offset for a particular length. To "rewrite" a file, the second DOSOpen () listed above must be changed to DOSCreate (). The document states that the DOSCreate () will truncate the file if it exists or create a file if it does not exist. The call to DOSCreate () returns a file handle that can be used on subsequent calls to DOSWrite () and DOSClose (). FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Bug in TTSTransactionStatus DOCUMENT ID#: FYI.A.1530 DATE: 15JAN93 PRODUCT: Network C for NLMs PRODUCT VERSION: SDKe SUPERSEDES: NA SYMPTOM Incorrect Transaction completed status ISSUE/PROBLEM When using the TTSTransactionStatus() call on the local server, CLIB is not long swapping the transaction number. An incorrect transaction number will result one of two problems. The TTSTransactionStatus() call may report that the transaction has completed, erroneously; or it may never show the transaction as completed. SOLUTION With CLIB v3.11d and earlier, when using the TTSTransactionStatus() call on the local server, LongSwap() the transaction number. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Closing Temporary Socket in BeginDiagnostics() DOCUMENT ID#: FYI.A.4903 DATE: 15JAN93 PRODUCT: NetWare C Interface DOS PRODUCT VERSION: 1.2 SUPERSEDES: NA SYMPTOM Multiple calls to BeginDiagnostics() fails after the eleventh attempt when searching for a target. ISSUE/PROBLEM BeginDiagnostics() function does not close the temporary socket. This is an example from DIAG.C: int GetRemoteSPXSocket( BeginDiagnosticStruct *destination, BYTE *cList ) * * tempSocket = (WORD)0x4545; if( IPXOpenSocket((BYTE *)&tempSocket, 0) ) /* after the 11th call, it now returns the 254 here */ return 1; IPXRecvECB.socketNumber = tempSocket; * * /* normally returns a 252 error here for the first 11 calls */ if ( IPXRecvECB.inUseFlag || IPXRecvECB.completionCode ) return IPXRecvECB.completionCode /* no response received */ int BeginDiagnostics(destination, connectionID, componentList ) * * /* first open a socket then init receive ECBs */ tempSocket = (WORD)0x00; /* let IPX pick socket number */ ccode = IPXOpenSocket((BYTE)&tempSocket, 0); /* call to function */ if( (ccode = GetRemoteSPXSocket(destination,componentList)) != 0 ) Error = COULD_NOT_OPEN_SOCKET; else { for (i=0; i<RESPONSE_ECBS; i++) { * * if (Error == NO_ERRORS) { * * if (ccode == 0) { * * else Error = COULD_NOT_BEGIN_CONNECTION; if (Error != NO_ERRORS) IPXCloseSocket (thisECB.socketNumber); } else Error = COULD_NOT_OPEN_SOCKET; /******************************************** NOTE THAT THE TEMPORARY SOCKET IS NOT CLOSED BEFORE THE RETURN (my comments) ********************************************/ return (Error); SOLUTION The fix is in the source code, DIAG.C. The function, IPXCloseSocket(), must be called when an error occurs. int BeginDiagnostics(destination, connectionID, componentList ) * * /* first open a socket then init receive ECB's */ tempSocket = (WORD)0x00; /* let IPX pick socket number */ ccode = IPXOpenSocket((BYTE)&tempSocket, 0); /* call to function */ if( (ccode = GetRemoteSPXSocket(destination,componentList)) != 0 ) Error = COULD_NOT_OPEN_SOCKET; else { for (i=0; i<RESPONSE_ECBS; i++) { * * if (Error == NO_ERRORS) { * * if (ccode == 0) { * * else Error = COULD_NOT_BEGIN_CONNECTION; /**************************************** Comment out or remove this section as it is not necessary. if (Error != NO_ERRORS) IPXCloseSocket (thisECB.socketNumber); *****************************************/ } else Error = COULD_NOT_OPEN_SOCKET; /* place fix here - close temporary socket */ IPXCloseSocket (tempSocket); return (Error); FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: OS/2 Requester Update, NSD201, Interferes with NWTools. DOCUMENT ID#: FYI.A.6206 DATE: 13JAN93 PRODUCT: NetWare OS/2 SDK PRODUCT VERSION: 2.0 SUPERSEDES: NA SYMPTOM NWTools script files no longer work after NSD201 applied. ISSUE/PROBLEM NWTools script files, *.NWS, that are created with version 2.0A of the OS/2 Requester will not run properly when the drivers have been updated with NSD201. Specific examples include not being able to attach to a server with an NWS file. The problem is apparently with NWTOOLS.EXE and NWTOOLS.DLL included with NSD201. New script files may not work correctly either. SOLUTION Save a backup copy of NWTOOLS.EXE and NWTOOLS.DLL before installing NSD201. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Interrupt Line 21, Function 3F Bug in Shell DOCUMENT ID#: FYI.A.6006 DATE: 13JAN93 PRODUCT: NetWare Shell PRODUCT VERSION: 3.31 SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM If a section of a file is locked with Interrupt line 21 function 5C00 and another workstation using the file tries to read from the locked area the call appears to succeed, even though it should fail. The carry flag is supposed to be set and an error code returned in the AX register. The error code (5 in this case) is being returned but the carry flag is not being set so the contents of the AX register are processed as the number of bytes read instead of as an error code. There is no way to tell if an error has occurred in this case. This bug has been found in NETX.EXE v3.26 and v3.31 but may exist in others. SOLUTION NA FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: How to Attach to Multiple File Servers with the Same Password DOCUMENT ID#: FYI.A.2947 DATE: 12JAN93 PRODUCT: NetWare C for Windows PRODUCT VERSION: 1.3 SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM If a user has the same password across multiple file servers, how can a developer write an application that does not prompt this user for their password every time they attach to a different file server? If a user is logged in to one server and needs to attach to another file server, the user's login script can be modified to contain add the attach command to the other file servers. However, the user will have to synchronize passwords across multiple file servers to avoid having to enter a password every time attaching to a new file server. This is not the case on the DOS command line, regardless of the fact that the user's passwords are synchronized or not on multiple servers. If the user is logged in to one server and wants to attach to another server, the password will have to be reentered. The reason is that the attach login script command has a different set of code than the attach command on the DOS command line. The attach login script command will not prompt the user for a password if the password is synchronized because it is built into the login routine. However, the attach command on the DOS command line will always prompt for a password. SOLUTION There is no way to attach to multiple servers without entering the password. However, Novell has a set of code that can be purchased just like any other product. This code will enable an application to attach/login to multiple servers without having the user enter each password. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: min() and max() Are Both Macros and Functions DOCUMENT ID#: FYI.A.6007 DATE: 08JAN93 PRODUCT: Network C for NLMs PRODUCT VERSION: 2.0d SUPERSEDES: NA SYMPTOM Compiler errors in STDLIB.H ISSUE/PROBLEM min() and max() are defined as macros in STREAM.H but are prototyped as functions in STDLIB.H. If STREAM.H is included before STDLIB.H, the compiler attempts to expand the prototype in STDLIB.H with the macro from STREAM.H. This results in syntax errors in STDLIB.H. SOLUTION Always include STREAM.H after STDLIB.H, or go into the STDLIB.H file and replace the prototypes with copies of the macro definitions from STREAM.H. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: VerifyNetworkSerialNumber() Causes Lost Connection DOCUMENT ID#: FYI.A.1329 DATE: 08JAN93 PRODUCT: NetWare System Calls PRODUCT VERSION: 1.2 SUPERSEDES: NA SYMPTOM A call to VerifyNetworkSerialNumber() with an invalid serial number will cause the calling workstation to lose its network connection. ISSUE/PROBLEM If the networkSerialNumber parameter does not match the network's serial number, the calling workstation will lose its connection to the network. The documentation does not state this; however, this is the way the function is supposed to work. The return values are only valid if the match occurs and some other error causes a nonzero return code. SOLUTION NA FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Home Directory Flag DOCUMENT ID#: FYI.A.3861 DATE: 06JAN93 PRODUCT: NetWare C Interface DOS PRODUCT VERSION: 1.2 SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM Where is the flag stored for creating the home directory for a newly created user? SOLUTION This flag, which is 1 byte, is stored at offset 64 in the USER_DEFAULTS property of the SUPERVISOR. If it is nonzero, SYSCON will prompt for the creation of the home directory if a new user is created. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Status 517 with XQL and Forest and Trees DOCUMENT ID#: FYI.A.2120 DATE: 31JAN93 PRODUCT: XQL PRODUCT VERSION: 2.11 SUPERSEDES: NA SYMPTOM Status 517 returned on SELECT statement ISSUE/PROBLEM When accessing Platinum DDFs using Forest and Trees for Windows, if XQL v2.11 is loaded, a SELECT * FROM <TableName> statement will return a status 517 - "The From Clause is Missing" when obviously a FROM clause is present. SOLUTION Platinum DDFs delimit their table names with semicolons that causes XQL to interpret the table name; as the end of the SQL statement, thus, producing a status 517. Newer DDFs that do not have these semicolon delimiters are available from Platinum. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Outer Join on a Computed Field DOCUMENT ID#: FYI.A.1775 DATE: 29JAN93 PRODUCT: NetWare SQL PRODUCT VERSION: 3.0 SUPERSEDES: NA SYMPTOM Status 875; Status 220 ISSUE/PROBLEM When a CREATE VIEW statement is used to create a view with a computed field whose resulting type is an integer, that computed field is considered to be a 4-byte integer. This is important when using this field as part of an outer (or null) join because the data type and length of the join fields must match exactly for an outer join. For example, in the following statement, the field T2 is a 4-byte integer containing the value 100: CREATE VIEW Test (T1, T2) AS SELECT F1, 100 FROM Tbl1 Consequently, the following statement will only work if TBL2.FLD is a 4-byte integer and is also an index (or first segment of an index) on table Tbl2: SELECT * FROM Test, Tbl2 WHERE Test.T2 = Tbl2.fld(+) If either of these conditions is not met, a status 220 "No Matching Index on Secondary Keys" will be returned. Currently, there is a problem with NetWare SQL v3.0b where the above SELECT statement will return an error 875 "Only a right Outer Join Is Supported," even if TBL2.FLD is a 4-byte integer and an index. SOLUTION If the view is created at the Relational Primitive level instead of using SQL statements, the xCompute function is used to specify the computed field. The xCompute function has parameters that allow the application to specify both the type and size of the resulting field. In this case, the computed field can be created as a 2- or 4-byte integer, whichever is needed for the outer join. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Blank User in USER.DDF Causes Security Problems in Xtrieve DOCUMENT ID#: FYI.A.1130 DATE: 27JAN93 PRODUCT: Xtrieve PLUS PRODUCT VERSION: 4.1x SUPERSEDES: NA SYMPTOM Status 205 when loading Xtrieve PLUS ISSUE/PROBLEM Years ago, it was possible to set up a blank user when installing security on data dictionary files. Currently, blank users are not supported. If a blank user exists in USER.DDF, then Xtrieve cannot be loaded without returning a status 205, which indicates "Invalid Password." The reason this error occurs is with the way Xtrieve logs into a set of DDF files. Xtrieve first attempts an xLogin to the dictionaries. If a status 209 (Invalid User) is returned, Xtrieve attempts to do another xLogin prompting for the user name and password. However, if anything other than a status 209 is returned to Xtrieve on the first xLogin call, then Xtrieve will not prompt the user for the user name and password. When Xtrieve attempts its first xLogin call, it always passes a blank user name and a blank password. Normally, this would return status 209 on a dictionary with security installed. However, because there is a blank entry in the USER.DDF file, a status 205 is returned instead. Because Xtrieve does not trap for anything but a status 209 on the xLogin, the status 205 would be relayed to the user of Xtrieve. It is interesting to note that XQLI will prompt for a username and password if security is installed on the data dictionary files, without attempting an initial XQLLogin call. XQLI will prompt the user for a password even if the user name is blank. So, the status 205 will not occur when logging in through XQLI unless the password specified is invalid. SOLUTION To work around the problem, remove the blank user from USER.DDF. BSIM.EXE, B.EXE, or any utility that provides Btrieve or XQLP function calls will do the trick. The DDF files have Btrieve owner names on them when security is installed. The Btrieve owner name on the DDF files will be the same as the master password specified when security was installed. The USER.DDF file can be checked for a blank user first, by running BUTIL -SAVE down key path 0. If there is a blank user, then using a Btrieve or XQL utility, read the record with the blank user then delete it from the Btrieve file. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Update Problem with NetWare SQL DOCUMENT ID#: FYI.A.1776 DATE: 26JAN93 PRODUCT: NetWare SQL PRODUCT VERSION: 3.0b SUPERSEDES: NA SYMPTOM Only one record updated ISSUE/PROBLEM If an UPDATE SQL statement is sent to NetWare SQL that has a restriction based on a field that is an index, only the first record matching the restriction will be updated. Example: UPDATE Appointments SET Amount^Due = 0.00 WHERE ID > 0 This command will only update the first record having ID > 0 if ID is an index in the Appointments table. All other records will remain as they were. This problem was introduced by the December patches for NetWare SQL v3.0. SOLUTION Use NetWare SQL with the September patch release installed. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: Running Out of NetWare SQL Connections DOCUMENT ID#: FYI.A.2948 DATE: 25JAN93 PRODUCT: NetWare SQL PRODUCT VERSION: 3.0 SUPERSEDES: NA SYMPTOM Status 266 on a xLogin or XQLLogin call ISSUE/PROBLEM The NetWare SQL documentation states the Error Message 266 "Number of Sessions Logged in Exceeds Maximum." However, it does not provide any explanation on the real reason for this message. The documentation should state that if a five-user copy of NetWare SQL is installed and all five connections are in use, a sixth user will not be able to log into a database. The NetWare SQL Monitor Utility (NDBMON.NLM) can be used to see which users currently have connections to NetWare SQL. SOLUTION Use only what is allowed in terms of SQL connections on your SQL server. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: VIEW.DDF and Owner Names DOCUMENT ID#: FYI.A.1131 DATE: 22JAN93 PRODUCT: Xtrieve Plus PRODUCT VERSION: 4.1x SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM When security is installed on a set of data dictionary files, each .DDF file is assigned a Btrieve owner name that is the same as the Master password with one exception: the VIEW.DDF file does not have a Btrieve owner name assigned. Why is this the case? SOLUTION Because multiple VIEW.DDF files can reference one or more set of DDFs, these files do not "belong" to any particular set of DDFs and cannot be assigned an owner name specific to one set of DDFs. Therefore, there is never an owner name assigned to a VIEW.DDF file. There is only one exception to having multiple VIEW.DDF files that reference one set of DDFs; see FYI.A.1120 for this information pertaining to named database support under NetWare SQL 3.0. FYI (Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.) TITLE: More on XQL and .SHR Files DOCUMENT ID#: FYI.A.1777 DATE: 12JAN93 PRODUCT: XQL for DOS PRODUCT VERSION: 2.11 SUPERSEDES: NA SYMPTOM NA ISSUE/PROBLEM In a previous FYI (FYI.A.1759, XQL and .SHR Files), a description of how XQL creates and maintains a .SHR file was explained. Another anomaly has been found regarding this issue. If XQL is patched so that it can be accessed from within Windows and then loaded from the WINSTART.BAT file, the .SHR file is created in the users current directory when Windows was started. Subsequently, if the user opens a DOS session and from the same directory, tries to load XQL again, one of two things will happen: 1. If DOS SHARE was loaded before Windows, a Sharing Violation Error will be returned and XQL will not load 2. If DOS SHARE was not loaded, XQL will overwrite the .SHR file already present with a new .SHR file. Subsequently, unloading XQL from this DOS session will cause this .SHR file to be deleted. This means that the XQL that was loaded by WINSTART.BAT no longer has an available .SHR file to use. This will eventually lead to status 202 or 821 (Invalid Cursor ID) errors to be returned. The previous situations occur only when the .SHR files are being created on a local drive. If the current working directory is a NetWare drive, this problem does not exist; two .SHR files are properly created and maintained in the same NetWare directory. SOLUTION If using a local drive, load XQL inside the DOS session from a different directory than the current working directory when Windows was started or specify an /x: parameter on the XQL load line pointing to a different directory. See the previous FYI.A.1759 for more information about the /x: parameter.